Fixed in the first commit. Added NewPermissionsContentsReadChecksWritePRRead() to permissions_factory.go (contents:read + checks:write + pull-requests:read) and updated the create-check-run PermissionBuilder in safe_output_handlers.go to use it when safeOutputs.CreateCheckRun.Target != "".

[/tdd] The pulls.get catch block has no test coverage — if the GitHub API returns a 404 (non-existent PR) or a 403 (auth failure), this error path silently goes untested.

it("returns error when pulls.get throws", async () => {
  mockGithub.rest.pulls = {
    get: async () => { throw new Error("Not Found"); },
  };
  const { main } = require("./create_check_run.cjs");
  const handler = await main({ max: 10, target: "*" });
  const result = await handler(
    { type: "create_check_run", pull_request_number: 42, conclusion: "success", title: "T", summary: "S" },
    {}
  );
  expect(result.success).toBe(false);
  expect(result.error).toContain("Failed to resolve pull request");
});

Added "returns error when pulls.get throws (e.g. 404 or 403)" test in the target resolution describe block. It stubs mockGithub.rest.pulls.get to throw new Error("Not Found") and asserts result.success === false with result.error containing "Failed to resolve pull request".

[/tdd] The for _, step := range steps loop is conditional — if addHandlerManagerConfigEnvVar generates no step containing GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG, the loop body never executes, all assertions are skipped, and the test passes vacuously. This is the same pattern as TestHandlerConfigClosePullRequestTargetRepo so it is pre-existing, but worth locking down.

found := false
for _, step := range steps {
    if strings.Contains(step, "GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG") {
        found = true
        // ... existing assertions ...
    }
}
require.True(t, found, "expected a step containing GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG")

Fixed. Added foundHandlerConfig := false before the loop, set to true inside the matching branch, and require.True(t, foundHandlerConfig, "Expected GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG in generated steps") after the loop.

x-synonyms annotation points to a field the runtime never reads: pullRequestNumber (camelCase) is listed as the synonym, but resolveTarget in safe_output_helpers.cjs only checks item.pull_request_number || item.pr_number || item.pr || item.pull_number — all snake_case. No camelCase alias is handled anywhere.

"x-synonyms": ["pr_number", "pr", "pull_number"]

const pullRequestNumberField =
  item.pull_request_number ||
  item.pullRequestNumber ||   // ADD
  item.pr_number ||
  item.pr ||
  item.pull_number;

Fixed pull_request_number's x-synonyms to list the actual alias property names the runtime checks: ["pr_number", "pr", "pull_number"]. Also added x-synonyms for each alias field. Applied to both actions/setup/js/safe_outputs_tools.json and pkg/workflow/js/safe_outputs_tools.json.

Live API call executes even in staged mode: githubClient.rest.pulls.get() runs before the isStaged check at line 182. In staged mode, the PR head SHA is fetched, used for nothing (the staged preview log does not include it), then discarded.

// Option A: skip the API call in staged mode
if (isStaged) {
  logStagedPreviewInfo(`Would create check run "${checkRunName}" targeting PR #${pullRequestNumber} with conclusion=${conclusion}, title="${resolvedTitle}"`);
  processedCount++;
  return { success: true, staged: true, ... };
}
// Only fetch the SHA when we actually need it
const { data: pullRequest } = await withRetry(...);

// Option B: include the SHA in the staged preview (already fetched, make it useful)
logStagedPreviewInfo(
  `Would create check run "${checkRunName}" on PR #${pullRequestNumber} @ ${headSha} with conclusion=${conclusion}, title="${resolvedTitle}"`
);

Fixed with Option A. The staged-mode early return now happens inside the checkRunTarget branch before the pulls.get call, so no live API call is made in staged mode. The staged preview message includes the PR number for context. Added a test "skips pulls.get API call and returns staged preview when target is set and staged mode is active" that asserts pullsGetCalled === false.

core.warning used for hard failures (shouldFail === true) instead of core.error: when target resolution fails with a genuine error — invalid PR number, target: "*" with no pull_request_number in the message — the log shows a yellow warning instead of a red error annotation, even though the workflow will ultimately fail. Compare assign_to_agent.cjs which correctly branches on shouldFail.

if (!targetResult.success) {
  if (targetResult.shouldFail) {
    core.error(targetResult.error);   // hard failure → red annotation
  } else {
    core.info(targetResult.error);    // expected soft skip → informational
  }
  return {
    success: false,
    error: targetResult.error,
    skipped: !targetResult.shouldFail,
  };
}

Fixed. Now uses core.error when targetResult.shouldFail is true (hard failure → red annotation) and core.info when it is false (expected soft skip → informational), mirroring the assign_to_agent.cjs pattern. The skipped field is now !targetResult.shouldFail.